In a conventional communications protocol development, and in particular VoIP deployment, each device, such as a phone, is configured with a local or dedicated server that is aware of all calling preferences, call routing, and options appropriate for that particular phone based on its statically known location. The general goal of peer-to-peer (P2P) or other decentralized serverless systems is to share the responsibilities of this server between all devices participating in the P2P overlay (in this document, P2P is used as a general term for decentralized serverless systems). Because this server functionality is now distributed among all of the devices without regard for location, there is no standard way to obtain information concerning how to make decisions based on the specific locations of any one or more devices in the overlay. Decentralizing a communications system in a P2P manner reduces the capital and operating expenses of the communication system, and they may scale over large deployments. For example, a P2P communications overlay might span multiple offices of a large multinational company. When placing an internal call, the device searches on the overlay to locate the destination of the call and initiates a VoIP call directly with the targeted device. However, when calling outside of the corporate phone system, an appropriate gateway to the traditional telephone network (PSTN) must be found. Two possible behaviors that might be desired are:                The calling device (caller) should locate a gateway (device that connects a VoIP call to the PSTN) in any one of the various corporate offices for which this call is a local call. This requires knowledge of which gateways are local to which area codes and exchanges.        Failing an appropriate gateway to make the call a local call, the caller might then fall back to the gateway closest to the caller, reasoning that if the call can't be local, at least it should find the shortest path across the network to deliver its VoIP traffic to a gateway before it is switched onto the PSTN.        
Implementing a system that provides these behaviors requires:                The ability to identify a configuration file for a device on the P2P communications overlay based on the device's IP address, or other statically known information that is location specific such as the default network router's IP address, one or more routers obtained via running traceroute or GPS location, for example.        The ability for a P2P communications device to identify the closest other device providing a service (such as providing a PSTN gateway), where “closest” can be by some network metric, typically longest matching IP address prefix, but could instead be number of hops, latency, congestion, or bandwidth capacity, for example.        The ability to identify a P2P communications device providing a particular service to other members of the overlay based on information about structures outside the P2P communications overlay, such as mapping from standard (e164) telephone numbers to the most appropriate gateway on the P2P communications network.        
In each of those cases, the searched-for device or information may be (or live on) a device actually participating in the overlay (referred to as a P2P communications device) or a device that is available to the members of the overlay and about which information is stored in the overlay by some other P2P communications device, but which is not actually participating in the overlay itself.
While conceptually simple, performing such a search in a P2P communications overlay is actually very difficult. P2P communications generally relies on a structured P2P overlay, which is optimized for questions such as “where is alice.smith@example-overlay located?” These questions can be answered in very little time, as the fundamental operation of a structured P2P overlay is a “fetch” that returns the resource stored corresponding to that exact search term. However, there is no support in a structured overlay for a fetch operation of the form “show me all of the registered users with the first name of alice in example-overlay,” (i.e. search for alice.*@example-overlay example-overlay). Because of the nature of a structured overlay, such a search is not possible without walking through the entire list of registered users, which is prohibitively expensive in larger networks. A similar problem arises when trying to locate a gateway for a specific phone number, e.g. 804-555-0101, or a gateway closest on the network to a particular caller. Generally, the overlay cannot store an entry for all numbers that might be dialed, which would require an entry for each phone number in the world, nor can it support searches of the form “give me the best outbound gateway for 804-555-*,” as described above. Similarly, when trying to find the closest gateway on the network, a P2P communications device typically only knows its IP address, e.g. 10.5.40.193, and its default router, e.g. 10.5.40.1. For a large branch office, the appropriate gateway might be several router hops away, at an IP address of 10.5.33.10. In such a configuration, with these example numbers, that gateway is likely responsible for over 4000 IP addresses. It is generally expensive, inefficient, and impractical to register all 4000 IP addresses for which the gateway is responsible in the overlay, so the potential caller cannot simply do a fetch for “10.5.40.193” in the overlay. Similarly, the device has no way of knowing that there is not a gateway responsible for its own local subnet (10.5.40), but instead for a higher level network prefix of 10.5.32/20, where 10.5.32/20 refers to 10.5 plus the first half of the eight bits used to represent the third number. In principle, a network administrator might configure all of the subnets the gateway is configured for into the overlay (e.g. including 10.5.40), but this then fails if the administrator is not aware that one of the subnets, for example 10.5.41, is itself split into two subnets 10.5.41.128/25 and 10.5.41.0/25.
The description thus far has been isolated to gateway location, but the general problem is broader, including issues such as locating local configuration files, which might be done in the same manner as searching for the closest (by IP prefix) gateway. Furthermore, while communication is most conventionally interpreted as bi-directional voice (telephone), the problems and methods described here apply equally to other communication forms, including other media types, uni-directional communication, data exchange and storage, etc.
Accordingly, there is a need to develop a reliable, accurate, and efficient way to obtain information concerning how to make decisions based on the specific locations of any one or more devices in the overlay.